Field of the Disclosure
Example embodiments of the present disclosure relate to the use of various techniques to protect communications between nodes.
Description of Related Art
Conventional web tracking solutions are typically separated into solutions loaded in a customer's server, for example, packet “sniffing” and Internet Information Services (IIS) log file analysis software, and solutions that attempt to track page level activity and which take the form of code inserted in a web page, third party Web “cookies” or software applications.
Various countries, corporations and Internet Service Providers block, censor or filter communications transmitted between two or more nodes. These communications can occur via the Internet, an Extranet, an Intranet or any other communication path that allows two nodes to communicate with one another. The mode of communication between the nodes is independent of the communication path and includes, for example, client/server, peer-to-peer and mainframe communication architectures. All types of communications, including, for example, wireless, cellular, wired, optical and satellite communications may be subject to censorship. Moreover, each of the various modes of communication including, for example, client-server, mainframe, distributed and peer-to-peer, are subject to censorship.
For example, a user may subscribe to an Internet sports package to watch sporting events over a network. The user can request and watch so-called out of market games, but the games are often censored (referred to as “blacked out”) when a team is playing locally and the televised version of the game is available on local free or pay television channels. The distributor of the content identifies the source of the content request and denies the request if the source is within the blackout areas.
FIG. 1 is a schematic diagram that shows nodes configured to send and receive requests for Target Content. An Intermediate Node 200 is configured to send and receive requests for Target Content 300. Intermediate Nodes 200, for example, proxy servers, were created at least in part to overcome censorship. Intermediate Nodes 200 may have a variety of configurations, capabilities, uses and placements, but need only be configured to respond to a request for Target Content 300 from a Requesting Node 100. Caching aside, a Node Request 400 sent from a Requesting Node 100 for Target Content 300 is not targeted at information typically stored locally by the Intermediate Node 200. Rather, the Node Request 400 is directed to information typically stored on yet another logical node, referred to herein as a Responding Node 600, which is physically or logically separate from the Intermediate Node 200. The Target Content 300 can be any content, for example, a service, a file, a connection, a web page, multimedia content or any other resource available over a network.
As another example, a user living in Los Angeles, Calif., representing a Requesting Node 100 may normally be blocked from obtaining Target Content 300, e.g., online TV, from a particular website which represents a Responding Node 600, because the website is configured to serve content only to users in the state of New York. Referring to FIG. 1, the user (at Requesting Node 100) may find an Intermediate Node 200 which requests the content from the Responding Node 600 from within the state of New York. The user sends a request for the content on the target website to the Intermediate Node 200, and the Intermediate Node 200 obtains the content, unrestricted in this example, from the target website and returns the content to the user in Los Angeles.
An Intermediate Node 200 may cache Target Content 300 obtained from the Responding Node 600 and still be considered an Intermediate Node 200 as long as the Requesting Node 100 is attempting to obtain the content data from the Responding Node 600. The data may be as simple as a low level communications request to check if a target server exists, or the data may be as complex as is supported on the communication path used and by the type of communications selected.
Nodes are logical constructs that can be physically implemented as discrete nodes, as part of other logical nodes or as a system. Requesting Nodes 100, Intermediate Nodes 200 and Responding Nodes 600 may exist at the same physical location, at completely disparate physical locations or at any combination thereof. Logical nodes may be comprised of different parts of a larger system, be themselves independent systems or be combined together in any combination. For example, a group of networked computers may each utilize a shared access point that is, itself, acting on behalf of a single logical node.
Many Intermediate Nodes 200 do not provide visibility to their data retrieval activities, and this lack of visibility causes difficulties with respect to the conventional use of Intermediate Nodes 200. Many Intermediate Nodes 200 do not provide the services that they purport to offer and, in fact, many nefarious Intermediate Nodes 200 cause more harm than any benefit they may provide. Harmful Intermediate Nodes 200 may download malicious content onto a Requesting Node 100, infiltrate the Requesting Node 100 by utilizing an array of techniques or promote the location of the Requesting Node 100 to dangerous third party groups. The Requesting Node 100 has almost no inherent protection from harmful Intermediate Nodes 200.
Moreover, using an Intermediate Node 200 through any sort of manual effort can be both technically challenging and time consuming for a typical end user. Intermediate Node 200 usage may require entries to be made in special sections of a Requesting Node's 100 operating system, file directory or some other configuration option, either directly or indirectly, and the only manner in which to determine if an Intermediate Node 200 is a viable and functional option is typically to use the Intermediate Node 200 and hope that nothing harmful occurs to the Requesting Node 100. Given the large number of Intermediate Nodes 200 providing intermittent connectivity, an end user may have to attempt to use hundreds or more of Intermediate Nodes 200 prior to finding a somewhat viable option.
Compounding these problems with the conventional use of Intermediate Nodes 200 is that an apparently functional Intermediate Node 200 may hide additional data within the Target Content 300 or perform actions beyond the scope of the Responding Node 600 that directly or indirectly affect the Requesting Node 100. While an end user may find an apparently functional Intermediate Node 200, through which requests for Target Content 300 are fulfilled, the end user may have no idea if the Intermediate Node 200 is also downloading malicious content or performing other potentially harmful operations. Furthermore, the end user has no way of knowing from which geographic region a given Intermediate Node 200 is sending out Content Requests 500 to the Responding Node 600. Overcoming censorship may rely on being perceived as requesting information from a distinct and safe geographic region but, given the conventional options in the market, choosing a specific location for an Intermediate Node 200 is not possible.
It should be noted that an end user is not required. Automated machine-to-machine communications, routing between systems, networking devices and other communication-related efforts may utilize an Intermediate Node 200 in place of an end user. An end user can, therefore, be a human, a computer, a program or some portion of code that produces a Node Request 400. Node Requests 400 may be generated directly or indirectly and with or without knowledge of the Intermediate Node 200. Content Requests 500 need not be defined as distinct or separate from the Node Requests 400, because the Content Request 500 can be a routed Node Request 400 or a context-based new message.
Utilizing an Intermediate Node 200 may aid in overcoming geography-based restrictions, and Intermediate Nodes 200 may provide additional benefits including, for example, cookie blocking, information compression and virus protection. However, communications between two or more nodes can be infiltrated, blocked, transformed or altered through some unwanted action by various mechanisms.
One known issue with communications between two nodes is referred to as “eavesdropping”, which includes any activity that somehow intercepts and reads, processes, stores or interacts with communication not intended for the node perpetuating the activity. A conventional solution to protect against eavesdropping is to utilize some form of encryption, for example, Virtual Private Networks (VPN) or Secure Socket Layer (SSL). As programming capabilities increase in power, these conventional technologies can be overcome and no longer provide the level of protection that they once offered. Furthermore, VPN typically requires static, specialized nodes, referred to as VPN Servers, and such a static approach may preclude dynamic communications by an increasingly mobile audience.
Another common communications issue is one of discovery, which can lead to inadvertent loss of privacy. Even if a technology such as VPN is successful is protecting the data within a given communication, potentially unwanted observers can still determine a significant amount of information about the given communication by examining the nodes involved in the communication. For example, if a factious site is providing music downloads for a popular music group and a node obtains content from that site, an observer could determine that the node likely downloaded music from the music group without ever needing to decrypt the protected data in the communication.
Furthermore, a potentially unwanted observer may observe the communication protocol used for the communication to gain another level of insight into a communication between two nodes. In the previous example, the potentially unwanted observer may determine, for example, that an FTP protocol was used between the known music site and the Requesting Node 100, thereby providing more evidence to the observer that music was downloaded. There is no available option for protecting the Responding Node 600 and the communication protocol from unwanted observation.
There is a range of conventional options for virtualizing application interfaces over a network. However, one of the main issues with these conventional approaches is the use of specialized ports, known protocols, and the high bandwidth required to port across entire operating system environments. These types of communications are highly visible and are typically targeted for eavesdropping purposes.
Accordingly, a need for more comprehensive communications protection between nodes exists.